Hi Peter, I just wanted to mention that we could have CAM7 + FV dycore give a buildnml error saying "moving mountains not supported by FV dycore, set to .false. is you want to run w/o it..." This would make users trying to do dycore intercomparisons aware that CAM7 isn't fully supported with FV. But there's also a lot of (historical) tuning logic in namelists_defaults.xml picked off of the FV "hgrids", and so the physics namelists will still differ for most compsets when running different dycores.

Hi Peter, I just wanted to mention that we could have CAM7 + FV dycore give a buildnml error saying "moving mountains not supported by FV dycore, set to .false. is you want to run w/o it..." This would make users trying to do dycore intercomparisons aware that CAM7 isn't fully supported with FV. But there's also a lot of (historical) tuning logic in namelists_defaults.xml picked off of the FV "hgrids", and so the physics namelists will still differ for most compsets when running different dycores.

Thanks for the suggestion! There’s no perfect solution here, so I’d recommend sticking with the current “under-the-hood” namelist selection. However, this means that QPC7 is only supported by SE and, soon, MPAS, but not FV or FV3 in terms of running the same CAM7 physics configuration. Perhaps we could include this information or a warning in the user’s guide.

Hi Peter, I just wanted to mention that we could have CAM7 + FV dycore give a buildnml error saying "moving mountains not supported by FV dycore, set to .false. is you want to run w/o it..." This would make users trying to do dycore intercomparisons aware that CAM7 isn't fully supported with FV. But there's also a lot of (historical) tuning logic in namelists_defaults.xml picked off of the FV "hgrids", and so the physics namelists will still differ for most compsets when running different dycores.

Thanks for the suggestion! There’s no perfect solution here, so I’d recommend sticking with the current “under-the-hood” namelist selection. However, this means that QPC7 is only supported by SE and, soon, MPAS, but not FV or FV3 in terms of running the same CAM7 physics configuration. Perhaps we could include this information or a warning in the user’s guide.

Peter/Adam - Are we good with the current code base?

Hi Peter, I just wanted to mention that we could have CAM7 + FV dycore give a buildnml error saying "moving mountains not supported by FV dycore, set to .false. is you want to run w/o it..." This would make users trying to do dycore intercomparisons aware that CAM7 isn't fully supported with FV. But there's also a lot of (historical) tuning logic in namelists_defaults.xml picked off of the FV "hgrids", and so the physics namelists will still differ for most compsets when running different dycores.

Thanks for the suggestion! There’s no perfect solution here, so I’d recommend sticking with the current “under-the-hood” namelist selection. However, this means that QPC7 is only supported by SE and, soon, MPAS, but not FV or FV3 in terms of running the same CAM7 physics configuration. Perhaps we could include this information or a warning in the user’s guide.

Peter/Adam - Are we good with the current code base?

yes

Here are the list of tests which are not LT/MT/WACCM or WACCMX which have answer changes - are these expected?

ERP_Ln9.ne30pg3_ne30pg3_mg17.FCnudged.derecho_intel.cam-outfrq9s (Overall: DIFF) details:
SMS_D_Ln9.f09_f09_mg17.FCts2nudged.derecho_intel.cam-outfrq9s_leapday (Overall: DIFF) details:
SMS_D_Ln9.f19_f19_mg17.QPC2000climo.derecho_intel.cam-outfrq3s_usecase (Overall: DIFF) details:
SMS_Ld1.f09_f09_mg17.FCHIST_GC.derecho_intel.cam-outfrq1d (Overall: DIFF) details:
SMS_Ld1.ne30pg3_ne30pg3_mg17.FC2010climo.derecho_intel.cam-outfrq1d (Overall: DIFF) details:

ERC_D_Ln9.f10_f10_mg37.QPC4.izumi_gnu.cam-outfrq3s_diags (Overall: DIFF) details:

All these versions of CAM physics (including CAM4) utilize the Beres scheme, which leads to changes in the results. This may indicate that the QBO needs to be retuned in older physics packages (@JulioTBacmeister); if using a different dycore it needs to be retuned anyway! Tagging @mbramberger, @tilmes, and @mijeong135 to keep them informed.

Since we have already introduced other modifications to CAM6 that do not preserve exact answers, I suggest moving forward. Additionally, the new code can be justified as being more physically consistent.

@PeterHjortLauritzen thanks for the note, it would be desirable to test the cam6 physics version before significant changes are made, because various people are trying to use this still. Is there a way to test what this would mean for dynamics and ozone?

@PeterHjortLauritzen thanks for the note, it would be desirable to test the cam6 physics version before significant changes are made, because various people are trying to use this still. Is there a way to test what this would mean for dynamics and ozone?

One can do a CAM6 run with this branch mv_mnt_upgrade and compare to CAM tag cam6_4_077

I was literally planning on tagging this within the hour. @tilmes let me know when you approve this PR moving forward. The next CESM tests will be waiting for this PR and the PUMAS PR which will follow it before they proceed with making a beta tag. Let me know if your testing will run into tomorrow, and I will swap the order of the PRs and put the PUMAS PR in first.

It may be useful to also test WACCM to make sure the QBO, and polar vortex is still looking fine, but I am not sure who would do the tests / evaluation. If we have a meeting tomorrow at 9am, maybe we can talk about this?

@cacraigucar please go ahead with finalizing the new tag.. I am suggesting to do the evaluation afterwards, there is no time to wait for this. Thanks Simone